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1  Introduction 


...  in  practice,  failure  is  still  far  less  frequently  the  result  of  bad  working  principles  than 
of  poor  detail  design.  Paht  and  Beitzfl] 

In  this  paper  we  introduce  the  theory  underlying  a  computer  program  that  selects  standard 
components  from  catalogs  in  order  to  implement  a  wide  variety  of  mechanical  designs.  The  user  of 
the  program  forms  a  schematic  by  combining  such  elements  as  those  in  Fig.  1.  Given  the  schematic, 
specifications,  and  a  utility  function,  the  program  returns  the  optimal  catalog  numbers. 

We  can  view  the  schematics  and  the  specifications  as  a  description  in  a  “high  level  (source) 
language’’,  and  the  catalog  numbers  as  a  description  in  a  “!ov.--leve!  (target)  language”.  Then,  by 
analogy  with  computer  language  compilers,  we  can  call  our  program  a  “mechanical  design  compiler" . 
Like  computer  language  compilers,  such  programs  should  improve  designer  productivity,  prevent 
errors,  and  allow  the  exploration  of  more  alternatives  in  greater  depth. 

1.1  Observations  on  Component  Selection 

Suppose  that  we  wanted  to  design  a  power  train  for  an  ice-cream  stirrer  (Figure  2).  We  will 
call  this  the  Toscanini’s  problem,  after  a  local  eatery.  Given  a  range  of  acceptable  stirring  speeds, 
the  torques  required,  and  a  catalog,  we  might  use  the  transmission  input-output  equations  RPMi  — 
{ratio){RPMo)  and  torque^  ~  {ratio)(torquei)  to  systematically  eliminate  those  transmissions  unable 
to  provide  the  required  speed  with  the  available  motors.  Then  we  might  eliminate  those  motors 
unable  to  provide  the  required  torque  through  any  of  the  remaining  transmissions. 

We  have  several  observations  to  make.  First,  note  that  in  this  example  we  think  about  sets 
of  artifacts  (e.g.  all  Dayton  3-phase  motors),  rather  than  particulaur  artifacts  (the  motor  that 
fell  off  the  loading  dock  yesterday).  Because  of  manufacturing  variation,  even  a  single  catalog 
number  designates  a  set  of  different  physical  artifacts,  which  may  or  may  not  be  interchangeable  in 


a  particular  design.  We  must  also  consider  sets  of  operating  conditions;  for  example,  the  ice  cream 
maker  may  be  nearly  empty,  or  full  of  cold  Double  Dutch  Chocolate.  We  cannot  always  assume  that 
the  maximum  load  is  the  only  one  that  matters — some  electric  motors  over-heat  unless  operated  at 
nearly  full  load. 

Second,  torque  is  a  quantiiaiivt  property,  normally  expressed  in  terms  of  real  numbers.  Our 
reasoning  about  torque  is  therefore  also  quantitative.  However,  while  the  torque  at  a  particular 
operating  condition  is  normally  represented  by  a  real  number,  the  torques  required  by  the  stirrer 
under  ail  ice-cream  viscosities  and  fill  levels  correspond  to  an  interval  of  real  numbers  (say  those 
from  10  to  40  newton-meters.) 

Third,  the  artifact  sets  are  organized,  for  example  by  horsepower  and  motor  speed.  We  can 
eliminate  large  sets  simultaneously  (e.g.  all  the  motors  of  less  than  1  horsepower). 

Finally,  the  only  mathematical  expressions  used  in  the  example  were  algebraic  equations.  Most 
designers  would  attack  the  problem  by  substituting  single  values  (say  for  the  largest  output  torque) 
into  the  equations,  then  comparing  the  results  with  other  single  values  from  catalogs.  If  asked 
to  justify  using  calculations  on  single  values  to  draw  conclusions  about  sets,  they  would  provide 
intuitive  arguments,  in  English  and  specific  to  the  particular  problem  being  considered. 

We  might  write  these  intuitions  into  an  “expert  system”,  and  that  program  might  work  well  in 
a  sufficiently  narrow  domain.  But  a  compiler  should  give  correct  results  on  every  design  which  can 
be  composed  from  the  schematic  elements.  It  therefore  needs  a  general  and  precise  theory,  which 
can  be  closely  examined  and  confidently  applied  to  diverse  design  problems. 

1.2  Preview 

This  paper  introduces  a  theory  for  quantitative  inference  about  sets  of  artifacts  and  operating 
conditions.  The  theory  provides  the  basis  for  a  mechanical  design  compiler  which  operates  by 
eliminating  unsatisfactory  alternatives  from  catalog  sets  of  artifacts. 

We  will  begin  with  a  brief  overview  of  the  compiler.  We  then  introduce  some  operations  on  real 
number  intervals.  From  intervals,  we  build  up  a  language  of  “labeled-intervals”,  or  “specifications”. 
Then,  we  illustrate  the  use  of  formal  operations  on  this  language  to  perform  quantitative  inferences 
in  the  solution  of  the  Toscanini’s  problem. 

2  A  design  compiler 

A  user  of  our  compiler  creates  a  design  schematic  by  pointing  in  sequence  at  displayed  icons. 
Each  icon  represents  a  computational  “object”,  which  normally  includes  a  list  of  catalog  numbers. 
Thus,  it  also  represents  the  set  of  real  artifacts  purchasable  by  ordering  from  the  catalog.  Associated 


Figure  2:  The  Toscanini’s  Problem 


with  each  catalog  number  are  specifications  in  the  labeled  interval  language.  Other  specifications 
automatically  abstracted  from  these,  along  with  equations  built  into  the  schematic  object,  describe 
the  whole  set  of  artifacts  represented  by  the  icon. 

The  schematic  assembly  process  establishes  an  identity  between  corresponding  variables  for  con¬ 
nected  components.  For  example,  in  the  Toscanini’s  problem  the  output  torque  of  the  transmission 
is  identified  with  the  input  torque  to  the  stirrer. 

Having  assembled  a  schematic,  the  user  supplies  specifications  in  the  labeled  interval  language 
for  the  most  convenient  objects,  usually  loads.  The  objects  pass  each  other  these  specifications,  the 
specifications  abstracted  from  the  artifact  sets,  and  new  specifications  derived  from  these  by  using 
equations.  The  objects  eliminate  from  consideration  incompatible  artifacts  (by  deleting  numbers 
or  groups  of  numbers  from  the  catalog  listing),  and  abstract  new  descriptions  for  the  resulting 
subsets.  In  the  Toscanini’s  problem,  the  user  might  specify  the  range  of  torques  required  at  the 
stirrer  input  shaft.  This  information,  propagated  through  equations  in  the  the  transmission  object, 
would  eliminate  those  motors  unable  to  supply  enough  torque  to  drive  the  load  through  any  of  ftie 
transmissions  under  consideration. 

Since  the  information  reaching  the  motor  object  is  about  all  the  possible  combinations  of  trans¬ 
mission  and  load,  the  compiler  does  not  explicitly  enumerate  the  alternative  combinations  of  motor 
and  transmission.  This  approach  may  be  contrasted  with  one  in  which  alternatives  are  generated, 
evaluated,  and  discarded  or  modified.  If  we  think  of  the  design  process  as  searching  a  space  of 
artifacts,  our  approach  works  by  eliminating  volumes  of  the  space,  while  the  other  evaluates  designs 
at  points  in  the  space.  At  any  time  during  our  program’s  operation,  the  schematii*  represents  the 
volume  of  the  artifact  space  which  has  not  been  eliminated. 

This  approach  has  several  advantages. 

•  Manufacturing  tolerances  and  operating  condition  variations  are  represented  explicitly. 

•  The  program  need  not  examine  each  alternative  individually. 

•  Elimination  inferences,  unlike  choice  inferences,  can  be  confidently  made  from  partial  infor¬ 
mation.  For  example,  our  program  does  not  yet  contain  a  representation  of  geometry,  but 
it  can  still  safely  eliminate  motors  providing  insufficient  torque.  It  could  noi  safely  choose  a 
motor — it  might  not  be  suitable  geometrically. 

•  The  inference  system  has  been  designed  to  produce  only  statements  which  are  true  of  each 
of  the  objects  being  considered  at  the  present  stage  of  compilation.  The  sets  of  artifacts 
considered  at  later  stages  will  be  subsets  of  this  set,  so  the  statement  will  still  be  true  of  each 
artifact.  Therefore,  statements  never  need  to  be  withdrawn. 

•  The  meaning  of  design  representations  is  often  left  intuitive;  designs  are  sometimes  said  to 
stand  for  an  “archetype”,  or  a  “partially  defined  object”.  In  contrast,  at  each  stage  of  the 
compilation  process  our  representation  stands  for  a  well-defined  set  of  physical  objects.  We 
can  therefore  evaluate  operations  by  using  physical  reasoning  about  the  objects  represented 
before  and  after  a  formal  operation. 

This  set-based  approach,  however,  has  one  significant  disadvantage:  conventional,  single-valued 
or  even  “constraint  propagating”  systems  of  mathematical  inference  are  inadequate  to  deal  explicitly 
with  sets  of  artifacts  and  operating  conditions.  We  now  begin  building  appropriate  inference  tools 
based  on  relationships  between  variables  and  intervals  of  real  number  values. 
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3  Some  Operations  on  Intervals 


We  need  to  work  with  sets  of  values  for  example  the  torque  required  to  drive  an  ice  cream  stirrer 
under  all  load  conditions.  We  might  write  0  <  torque  <  10  (in  our  favorite  units),  or  torque  6  [0  10] 
but  will  instead  write  {torque  0  10);  for  now,  the  reader  can  assume  these  statements  mean  the  same 
tiling. 

Using  this  notation,  we  will  present  eight  operations  on  intervcils.  Because  we  are  trying  to 
convey  a  general  understanding  we  will  present  the  operations  using  examples,  and  claim  without 
proof  that  under  appropriate  circumstances  the  operations  are  both  well  defined  and  computable. 
For  more  detail,  see  [2]. 

The  first  five  operations  used  by  our  design  compiler  are  straightforward,  and  are  illustrated  in 
the  following  examples. 

•  Intersection:  1  4),  (x  2  6))  — ►{x  2  4). 

•  .Mot-intersection; l/l((x  1  4),(x  2  6))  — ►False. 

•  Filled-union;  U((-c  I  4),{x  8  10))  — ►(x  I  10). 

•  Subset:  C  ((x  10  12),  (x  10  14))  — ►True. 

•  \ot-subset;  {(x  10  12),  (x  10  14))  — ►False. 

We  will  call  the  sixth  operation  Range.  Range  takes  an  implicit  equation  in  three  variables  and 
a  pair  of  intervals  in  two  of  the  variables,  and  returns  the  compatible  interval  in  the  third  variable. 
More  precisely,  suppose  that  g{x,y,z)  =  0  is  the  implicit  equation,  and  X  and  Y  are  intervals  in 
X  and  y  respectively.  Then  RANGE(:y,  X,  Y)  — ►  Z,  where  Z  is  the  minimal  interval  such  that  for 
every  assignment  of  x  G  X  and  y  ,  there  is  an  assignment  of  2  G  2  which  satisfies  g. 

Let  us  do  an  example.  Suppose  that  in  the  Toscanini’s  Problem,  we  had  available  transmission 
ratios  only  from  2  to  4,  and  we  knew  that  output  torques  above  8  would  damage  the  stirrer.  Figure  3 
represents  the  transmission  equation,  =  0,  by  showing  lines  of  constant  output  torque. 

From  the  figure  we  see  that  regardless  of  our  choice  of  transmissions,  any  motor  providing  input 
torque  above  4  will  induce  output  torque  above  8.  We  might  reasonably  conclude  that  regardless  of 
our  choice  of  transmission  we  should  not  use  any  motor  producing  running  torques  above  4. 

The  Range  operation  produces  the  appropriate  interval: 

Range(U - —  =  0,  (4  0  8),  {ratio  2  4)) — ►(t.  0  4). 

ratio 

t  he  Range  operation  is  equivalent  to  what  is  usually  called  the  constraint  propagation  of  inequal¬ 
ities,  and  has  been  well  explored[3].  However,  it  is  not  the  only  operation  of  interest.  Suppose  that 
instead  of  saying  that  the  stirrer  will  be  damaged  by  torques  above  8,  we  say  that  torques  ranging 
from  0  to  8  may  be  required  to  drive  it.  We  should  conclude  that  we  need  motors  able  to  provide 
torques  ranging  ranging  at  least  from  0  to  2;  see  Figure  4.  We  will  call  the  operation  producing  this 
interval  Domain;  it  can  be  defined  as  an  inverse  of  Range.  For  example, 

DoMAiN(<i - ^  =  0,  {t„  0  8),  {ratio  2  4)) — ►(<,•  0  2) 

ratio 

precisely  because 

RANGE(<i  -  =  0,  (<.  0  2),  {ratio  2  4)) — ►(<„  0  8). 

ratio 

Finally,  we  define  the  eighth  operation,  SuFFiclENT-PoiNTS,  as  another  sort  of  inverse  to 
Range.  Suppose  in  the  Toscanini’s  problem  we  knew  that  we  had  available  only  motor  torques 


Range 


Figure  3;  An  illustration  of  the  Range  operation 


Figure  4:  An  illustration  of  the  Domain  operation 

up  to  2,  and  we  needed  stirrer  torques  up  to  8.  Looking  ao  Figure  5  we  would  conclude  that  any 
transmission  ratio  of  4  or  above  would  do.  That  is, 

SuFPT(t,' - ^  =  0,  {to  0  8),  (<,  0  2))  — •■{ratio  4  oo) 

ratio 

because  for  all  ratios  in  [4  oo],  the  Range  of  the  ratio  and  the  input  torque  includes  the  output 
torque.  For  example,  a  ratio  of  5  would  give  the  output  torque  interval  0  to  10,  which  includes  the 
desired  interval,  0  to  8. 

RANGE(ti - =  0,  {U  0  2),  {ratio  5  5)) — •{U  0  10). 
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t. 
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Figure  5:  An  illustration  of  the  Sufficient-Points  operation 


All  of  the  operations  presented  £ire  sometimes  useful  in  design,  but  when  should  we  use  each  one? 
In  these  examples  we  used  our  experience  as  designers  to  decide  which  operation  would  produce  the 
desired  interval.  In  a  formal  system,  we  need  to  build  the  information  guiding  those  decisions  into 
the  specifications  themselves.  We  will  call  these  augmented  interved  statements  labeled  intervals. 

4  The  labeled  interval  specification  language 

We  will  return  to  the  examples  of  the  previous  section,  but  first  introduce  the  language  of  labeled 
intervals  using  an  even  simpler  design  problem — selecting  one  of  a  set  of  motors  to  be  connected 
directly  to  a  load  (Figure  6). 


Figure  6:  A  very  simple  power  train 


4.1  Limits  and  operati<ig  regions 

Suppose  that  we  know  that  each  of  some  set  of  motors  can  produce  torques  throughout  the 
interval  0  to  20,  but  that  damage  may  result  to  the  load  if  the  torque  goes  above  10.  We  wamt  to 
eliminate  these  motors  from  consideiation.  Given  only  the  intervals  ((t  0  20),  (t  0  10))  a  program 
would  not  have  enough  information  to  specify  what  operation  to  use.  For  example,  if  the  larger 
interval  applied  to  the  load  and  the  smaller  to  the  motors,  we  would  not  eliminate  the  motors.  We 
can  attach  the  information  required  using  the  following  labels. 

on/y 

The  Limits  label,  symbolised  by  [  J  ,  indicates  that  values  of  the  variable  will  or  must  be  drawn 

only 

only  from  the  interval.  Thus,  {[  ]  1  0  10)  means  that  the  torque  must  not  reverse  or  go  above  10. 

only 

Similarly,  the  tolerance  on  a  bearing  inner  diameter  can  be  expressed  as  ((  ]  d,-  2.99  3.01). 
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The  Operating- Region  label,  symbolized  by  .  iiulirales  that  the  variable  will  or  uiust 

assume  every  value  in  the  interval;  (''il'’*'  (  0  20)  indicates  that  the  motor  torque  can  at  least  range 
from  0  to  20  (and  perhaps  beyond.) 

We  will  later  define  a  rule  which  eliminates  these  motors  because,  for  the  variable  t,  the  operating- 
region  interval  is  not  a  subset  of  the  limit  interval. 

4.2  Required.  Assured,  and  No-stronger  labels 

Suppose  that  in  our  motor-load  example  we  want  the  load  speed  to  be  regulated  to  between  1750 
and  1800  rpm.  We  introduce  a  Required  (R)  interval  label,  moaning  that  the  statement  must  be 

only 

true  for  proper  function.  For  the  load,  we  can  write  (R  (  ]  /f/’.U1750  1800). 

Suppose  further  that  some  catalog  number  designates  a  set  of  high-slip  motors,  capable  of  reg¬ 
ulating  the  speed  only  well  enough  to  keep  it  between  1/2.5  and  1800.  We  introduce  the  No- 

only  «  , 

stronger-possible  (N)  label,  and  write  for  the  high  slip  motors  (N  (  ]  RPM\12o  1800).  Hy  this 
we  mean  that  we  cannot  specify  any  subset  of  these  motors  which  guarantees  stronger  limits.  (Be¬ 
cause  of  manufacturing  variation,  some  of  them  probably  do  guarantee  better  speed  regulation,  but 
w’e  cannot,  within  the  framework  given,  select  these.)  VVe  will  define  a  rule  which  eliminates  these 
motors  because  the  No-stronger-possible  limit  interval  for  RPAfis  not  a  subset  of  the  Required  limit 
interval. 

The  final  label  in  this  class  is  Assured  (A),  indicating  that  we  are  sure  a  particular  statement 
will  be  true  for  all  the  artifacts  represented  (under  appropriate  conditions).  Thus  for  our  high  slip 

only 

motors,  we  have  also  (A  [  ]  RPM1725  1800). 

We  have  illustrated  the  Assured,  Required,  and  No-stronger-possible  labels  only  in  conjunction 

with  the  Limit  ([  ]  )  label,  but  they  can  be  defined  comparably  in  conjunction  with  the  Operating- 
Range  )  label. 

Labeled  interval  descriptions  are  models  of  artifact  sets,  and  we  can  choose  the  level  of  abstraction 
of  the  model.  For  example,  there  is  a  torque  curve  for  each  motor  type,  which  would  allow  more 
accurate  prediction  of  the  speed  regulation  based  on  the  possible  torques.  If  we  chose  to  include 
the  torque  curve  in  our  describing  equations,  we  would  apply  labeled  interval  specifications  to  the 
equation 'a  coefficients. 

In  addition  to  the  labels  defined  above,  we  designate  each  quantity  as  either  a  state  variable 
or  a  parameter.  Parameters,  such  eis  gear  ratio,  are  fixed  at  manufacture,  while  state  variables 
like  torque  may  vary  during  operation. 

Each  labeled  interval  pertains  only  to  a  specified  set  of  operating  conditions  such  as  start-up  or 
normal  operating  conditions.  We  will  assume  “normal  operating  conditions”  throughout  this  paper. 

5  Operations  on  Labeled  Intervals 

The  key  activities  of  our  compiler  can  be  specified  by  three  groups  of  formal  operations  on 
labeled  intervals;  elimination,  abstraction,  and  specification  propagation. 

5.1  Elimination 

These  operations  eliminate  artifact  sets  whose  labeled  interval  specifications  conflict  with  the 
specifications  imposed  by  the  user  or  by  other  parts  of  the  design. 

We  represent  these  operations  using  patterns.  Suppose  that  for  our  motor-load  power  train  wo 

only 

Iiave  the  same  speed  regulation  requirement  as  above:  {R  [  ]  /2PMI750  1800).  We  want  to  elim- 
inate  motors  with  weaker  speed  regulation,  say  (N  (  ]  RPM1725  1800).  These  two  specifications 
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inatrli  the  pattern 


only  only 

(N  [  ]  A'  xi  Ju)  2  [  1  •'■i  •*■«) — ^eliminate, 

with  A'  taken  to  be  the  RF’M  and  xj  and  Xy  the  lower  and  upper  bounds  of  the  corresponding 
intervals. 

Since  the  No-stronger-possible  specification  is  not  a  subset  of  the  Required  specification,  the 
program  removes  the  relevant  catalog  numbers  from  the  associated  list. 


((R  A)'^r»'x...)  ^  ((RA)r'l  ^...) 

only  only 

((RA)(  )  x...)i7l((R  A)  [  jx.,.) 

only  only 

(N  [  1  x...)  2  {(R  A)  [  )  x...) 

((R  A)  T...)  2  (N  X...) 

Table  1.  Elimination  patterns 

.All  our  elimination  patterns  are  shown  in  Table  1  (with  the  arrow  and  the  word  ‘’eliminate" 
omitted  for  brevity).  When  the  list  "(R  A)”  appears  in  a  pattern,  it  can  be  matched  against  either 
a  Required  or  an  .Assured  statement. 

5.2  Abstraction 

In  the  Toscanini’s  problem,  we  want  to  evaluate  motor  alternatives  with  respect  to  the  set  of 
all  transmissions  under  consideration.  Therefore,  we  need  a  set  of  specifications  which  describe 
all  the  transmissions.  The  program  abstracts  these  specifications  from  the  previously  encoded 
descriptions  of  the  individual  “catalog  number”  subsets. 

The  program  uses  either  the  intersection  or  the  fHled-union  operation  to  combine  the  intervals 
associated  with  a  given  variable  and  pair  of  labels  in  each  subset.  For  eissured  limits  it  uses  the  filled- 

on/y  only 

union  operation,  so  for  example  it  combines  (A  (  ]  RPMWbO  1200)  and  (A  [  ]  RPM\7bO  1800} 

only 

to  form  (A  [  ]  RPMWbO  1800).  There  are  six  types  of  labeled  interval  defined  by  combining  the 
two  label  sets  (Assured,  Required,  No-stronger-possible)  and  (Limit,  Operating- Region).  Table  2 
shows  the  operation  appropriate  for  combining  each  type  of  labeled  interval. 


interval  type 

operation 

(A  ) 

n 

only  . 

(All) 

u 

(R  ) 

n 

only 

(R-[  i) 

u 

(N  ) 

u 

only  . 

(N  [  1  ) 

Table  2:  Abstraction  operations 


5.3  Propagating  Labeled  Intervals  Using  Ecpiations 

W’e  turn  now  to  a  more  complex  question;  how  can  we  propagate  labeled  intervals  through 
equations,  so  that,  for  example,  the  torque  requirements  for  the  ice  cream  stirrers  can  be  converted 
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into  torque  requirements  for  the  motors','  We  introduce  two  operations  on  labeled  intervals  and 
equations. 

The  first  is  represented  h\  the  following  pattern; 

only  <‘n/v 

((RA)[  ]  r,)  ((R  A)  [  1  r,)  ^(tq ,  tw,  t'a)  =  0 

only 

— -((RubA)  [  1  v-i  Range). 

The  labeled  interval  patterns  to  the  left  of  the  arrow  are  matched  with  potential  inputs  to 
the  operation,  while  the  pattern  to  the  right  of  the  arrow  defines  the  form  of  the  output.  The 
<2'  t'a)  =  0  ’  matches  equations  linking  the  two  input  variables  and  the  output  variable.  The 
"(R  A)"  in  the  input  patterns  again  indicate  that  the  operation  is  appropriate  fijr  either  Required 
or  Assured  statements.  The  "(RubA)”  in  the  output  indicates  that  the  output  will  be  Required 
unless  both  inputs  are  Assured,  iti  which  case  it  will  be  Assured.  Finally,  the  “Range"  in  the 
output  pattern  indicates  that  the  numeric  values  are  to  be  found  by  applying  the  Range  operation 
to  the  input  values. 

Suppose  again  that  in  the  Toscanini’s  Problem,  we  have  available  transmission  ratios  only  from 
2  to  4,  and  we  know  that  torques  above  10  would  damage  the  stirrer.  The  specifications  match  our 
pattern: 


only  only 

(R[  ]  <„0  10}  ~  {(R  A)  [  ]  vi) 

only  only 

(A  (  ]  ratto2  4)  ~  ((R.  A)  [  ]  ^2) 

=  0  ~  s(vi,t;2,t;3)  =0. 


only 

This  justifies  applying  the  Range  operation  to  form  (R  [  )  <,  0  5).  The  elimination  operations 
will  use  this  new  specification  to  eliminate  any  motor  producing  torques  above  5. 

The  second  operation  is  represented  by  the  pattern 


((R  a: 


every 


only 


Si)  <?<:  ((R  A)  (  ]  Pi)  k.  g{si,p2,S3)  =  0 


((RubA)  S3  Domain). 


Reading  the  pattern,  we  see  that  the  first  input  must  be  an  operating-region  interval  and  the 
second  a  limit.  The  first  input  and  the  output  variables  must  be  state  variables,  while  the  second 
input  variable  must  be  a  parameter.  The  output  interval  is  formed  by  applying  the  Domain  oper¬ 
ation  to  the  input  intervals.  The  (RubA)  rule  is  applied  again.  The  idea  is  that  if  we  need  a  state 
variable  to  tak'’  on  every  value  in  a  certain  operating-region,  and  we  have  some  limited  choices  of 
parameters  in  the  equation,  then  the  other  state  variable  must  take  on  values  over  a  sufficiently  large 
interval  to  satisfy  the  equation  with  at  least  one  of  the  parameters  available.  If  we  need  torques  up 
to  8  to  drive  the  stirrer,  we  can  match  the  specifications  with  the  pattern: 


(R  0  8)  ~  ((R  A) sj) 

only  only 

(A  [  ]  ratio2  4)  ~  ((R  A)  [  ]  p) 

~  (?(t;,,V2,U3)  =  0. 


We  therefore  apply  the  Domain  operation  to  form  (R  0  2);  the  motors  are  required  to 

supply  torques  throughout  the  operating-region  from  0  to  2.  Note  that  this  specification  does  not 
imply  that  the  input  torque  ti  can  never  be  greater  than  2,  but  rather  that  all  motors  considered 
must  be  able  to  supply  torques  of  at  least  2.  If  at  some  point  the  transmissions  of  ratio  4  are 
eliminated  from  consideration,  a  new  labeled  interval  requiring  higher  <,■  will  be  generated. 

Table  3  shows  all  the  propagation  operations.  Symbols  representing  the  aissociated  equations  are 
omitted  for  brevity.  The  list  “(p  s)”  may  be  matched  against  either  a  parameter  or  a  state  variable. 
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The  I  and  i  operations,  given  intervals  in  a  variable,  extend  the  interval  upward  to  infinity  or 
downward  to  zero  respectively.  The  label  indicates  that  the  variable  must  take  on  at  least  one 
value  in  the  interval;  see  [2]  for  details. 


(A  5,)  k(A  S2)  —(A  S3  Ran'^e) 

(R  Si)  &  (R  s,)  S3  Range) 

(N  si)  k  (N  sj)  — {N'''r>'  S3  Range) 

onlv  ontij  only 

((R  A)  [  ]  (pi  si))  k  ((R  A)  [  ]  (p2  S2))  — '((R  ubA)  [  ]  (ps  S3)  Range) 

((R  A)  "T!'  si)  k  ((R  A)  r'l  (P2  S2))  ^{(R  ubA)  S3  Domain) 

{(R  A)  ' s,)  k  ((R  A)  r’l  S2)  — ‘(R  T'\  P3  SufPt) 

(N  si)  (N  P2)  — ►(N  S3  Domain) 

(N  si)  k  ((A  R)  r'l  (P2  S2))  — (N  S3  Range) 

(A  ' s,)  k  (N  r'l  P2)  — (N  r'l  S3  Range) 

(R  "r*'  si)  &  (N  "''if*'  S2)  — (R  r'l  P3  SufPt) 

(R  si)  k  (N  "T!'  S2)  — (R  S3  Domain) 

only  only  only 

(N  [  ]  (pi  si))  &  ((A  R)  [  ]  (P2  S2)) — ►(N  [  ]  (p3  S3)  Domain) 

on/y  only  only 

(R  (  ]  si)  &  (N  (  1  P2)  — ►(R  (  1  S3  Domain) 

(R  si)  k  (N  r'l  P&)  — >(R  S3  Range) 

((R  A)  si)  k  {(R  A)  r'l  (P2  S2))  — ((R  ubA)  S3  SufPt) 

((R  A)  * si)  k  (N  S2)  — ►((R  ubA)  S3  SufPt) 

((R  A)  si)  k  ((R  A)  S2) 

— ►((R  ubA)  ^  83  (Domain(si,S2)  DDomainO  (si),S2))  ) 

u 

(DOMAIN(si,S2)  nDOMAlN(l  (si),S2)) 

((R  A)  Si)  k  ((R  A)  S2) 

— ►((R  ubA)  S3  (SufPt(si,S2)  nSUFPT(t  (si),S2))  ) 

u 

(SufPt(si,S2)  DSufPtO  (si),S2)) 

((R  A)  (r'l  )  (Pi  Si))  k  ((R  A)  S2)  ((R  ubA)  S3  Range) 

((R  A)  (r'l  )  (PI  si))  k  ((R  A)  S2)  — ((R  ubA)  ["']  P3  Range) 

((R  A)  si)  k  (N  r'l  Pz)  — ►((R  ut^A)  S3  Domain) _ 

Table  3:  Inference  patterns  using  equations. 


5.4  Review  of  the  literature 

We  have  been  influenced  by  a  number  of  general  idea.s.  De  KIeer[4]  argued  that  much  of  our 
knowledge  about  the  physical  world  is  left  implicit  by  classical  mechanics.  “Constraint  propagation” 
can  be  traced  to  Sutherland[5].  “Silicon  compilers” [6]  suggested  that  design  operations  could  be 
regarded  as  transformations  of  formal  descriptive  languages.  Chapman[7]  argued  that  “partially 
completed  plans”  represent  sets  of  possible  plans;  we  have  directly  adapted  this  idea  to  physical 
artifacts. 
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Work  using  artificial  intelligence  methods  to  study  mechanical  design  can  be  arranged  along  a 
spectrum  of  increasing  abstraction  from  human  design  activity.  At  the  most  abstract  point  of  this 
spectrum,  Fitzhorn  and  his  students  are  using  Turing  machine  models  to  establish  fundamental 
conclusions  about  the  design  process[8],  while  Yoshikawa[9]  views  design  descriptions  as  topologies 
on  a  space  similar  to  our  artifact  space.  Conversely,  at  the  “human  model”  end,  Waldron  and 
Waldron[10],  and  Ullman  and  Dietterich[ll]  study  human  designers  using  the  methods  of  the  social 
sciences. 

Toward  the  “human  model”  end,  Shin-Orr[12],  Brown[13],  and  Mittal,  Morjaria,  and  Dym[14], 
have  developed  “expert  systems”  to  design  multiple-spindle  gear  drives,  air-cylinders,  and  paper- 
paths  respectively.  These  programs  use  hierarchical  control,  trial  solutions  and  back-tracking.  They 
apply  heuristics  obtained  by  studying  experts,  and  appear  to  give  nearly  expert  performance  in 
narrowly  defined  domains. 

Near  the  center  of  the  spectrum  we  might  place  work  focusing  on  a  single  strategy.  The  Dominic 
series  of  programs  by  Dixon  and  his  students[15],  implement  a  modified  “hill-climbing”  procedure, 
searching  from  point  to  point  in  the  design  space.  Problems  like  the  Toscanini’s  are  coded  by  the 
programmer,  rather  than  assembled  from  schematics,  but  much  of  the  system  is  independent  of  the 
particular  problem.  Also  by  Dixon  and  his  students  are  a  series  of  works  on  “design  by  features”  [16]. 
Features  are  geometrically  oriented  entities  (corners,  bosses).  It  appears  that  compatibility  between 
mating  features  must  be  maintained  by  “hard  code”,  and  that  in  general  the  systems  warn  if  con¬ 
straints  are  violated,  rather  than  using  constraints  to  set  values.  Papalambros[17],  and  Rinderle[18] 
are  working  on  a  variety  of  design  support  issues  and  tools,  spread  across  the  spectrum. 

Our  work  belongs  with  a  cluster  slightly  further  toward  the  more  abstract  end  of  the  spectrum. 
Ulrich  and  Seering  [19]  use  “generate,  test,  and  debug”  schemes  to  transform  differential  equations 
into  schematics,  and  schematics  into  more  specific  pictorial  representations.  The  program  does  not 
use  quantitative  methods  for  elimination  or  optimization,  instead  presenting  the  human  designer 
with  a  variety  of  alternatives.  Wood  and  Antonsson[20,  21]  have  been  exploring  the  use  of  fuzzy  set 
theory  and  fuzzy  arithmetic  in  analyzing  designs. 

A  version  of  the  idea  that  designs  represent  sets  of  artifacts  appeared  in  Requicha’s[22]  theoretical 
study  of  geometric  tolerancing. 

Agogino  and  Cagan[23]  extend  formal  optimization  methods,  for  example  deriving  a  torsion  tube 
from  a  torsion  bar  by  dividing  the  moment  integral  into  two  regions  and  optimizing  over  them. [23] 

Findly,  a  good  deal  of  work  at  about  this  level  of  abstraction  uses  constraint  propagation. 
Gossard  and  his  students  explore  “variational  geometry”,  in  which  systems  of  equations  are  tied 
to  geometric  descriptions  of  parts.  Much  of  this  work  has  been  directed  to  issues  of  computational 
efficiency,  but  see  Serrano[24]  for  a  system  that  allows  the  designer  to  use  schematics  in  building 
an  equation  network  for  analysis  (not  compilation)  of  a  mechanical  design.  Popplestone[25]  et  al 
have  used  an  algebraic  constraint  propagator  as  part  of  a  very  large  system  with  similar  goals. 
Gross [26]proposes  a  similar  system  for  architectural  design.  Fleming[27],  propagates  the  geometric 
tolerances  of  parts.  Steinberg  et  al[28]  have  partially  integrated  top-down  refinement  (in  the  sense 
of  progressively  dividing  a  design  problem  into  modules)  and  constr^nt  propagation  with  a  hill¬ 
climbing  mechanism. 

These  constraint  propagation  systems,  and  our  earlier  work[29,  30],  propagate  equalities  only,  or 
else  give  intervals  the  limit  interpretation  and  propagate  them  using  only  equivalents  to  the  range 
operation.  However,  see  Lozano-Perez  et  al[31]  for  a  generalization  of  the  domain  operation,  the 
pre-image,  used  to  formulate  robot  motion  plans  under  uncertainty. 

5.5  A  summary,  with  contrasts 

We  can  now  summarize  our  work,  emphasizing  points  of  contrast  with  the  “mechanical  design” 
programs  mentioned  above. 
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•  We  provide  an  explicit  and  “compositional"  high  level  language  in  which  designers  can  define 
new  systems  ^lnd  problems.  Formal  operations  on  this  language  automatically  transform  high- 
level  descriptions  into  detailed  descriptions. 

•  Our  design  descriptions  explicitly  represent  sets  of  artifacts  and  operating  conditions,  rather 
than  a  single  or  “archetypical”  artifact  under  a  single  operating  condition. 

•  We  search  by  progressively  narrowing  volumes  of  the  artifact  space,  rather  than  from  point  to 
point  in  that  space. 

•  We  add  the  domain  and  sufficient-points  operations  on  intervals  to  the  range  constraint- 
propagating  operation. 

•  We  add  the  operating  region  interpretation  of  intervals  to  the  limit  interpretation. 

•  We  divide  specification  statements  into  those  which  are  true  of  all  the  artifacts  represented 
(Assured),  those  which  must  be  true  of  the  final  design  (Required),  and  those  which  may  or 
may  not  be  true  but  which  cannot  be  strengthened  (No-stronger-possible). 

•  We  divide  variables  into  “causality  classes”  (parameters  vs  state-variables). 

We  believe  these  concepts  are  sufficient  to  support  design  compilation  over  a  much  of  the  power 
transmission  system  domain.  (We  have  not  attempted  to  design  servo-systems,  or  use  components 
which  are  not  pre-cataloged.)  The  design  compiler  program  we  have  written  tests  this  hypothesis. 

6  Results 

We  have  tested  our  design  compiler  on  more  than  a  dozen  arrangements  of  components.  The 
data  base  for  these  tests  includes  specifications  on  such  quantities  as  motor  speeds  and  torques, 
pump  pressure  ratings,  efficiencies,  and  displaced  volumes,  etc,  as  well  as  the  related  power  trans¬ 
mission  equations.  Also  included  are  equations  for  determining  such  quantities  as  ball  screw  critical 
frequency  and  buckling  load. 

There  are  often  multiple  solutions  satisfying  the  specifications  for  a  given  problem.  Also,  because 
information  is  lost  in  abstracting,  a  group  of  alternatives  may  “hide”  some  unsatisfactory  ones.  The 
system  therefore  interleaves  elimination  steps  with  search  steps,  looking  for  the  optimum  solution 
as  defined  by  a  user-supplied  objective  function. 

Fig.  7  shows  an  example  component  arrangement.  The  numbers  in  the  schematic  symbols 
indicate  the  number  of  line  items  in  the  catalogs  represented;  there  are  initially  404,352  possible 
combinations.  With  reasonable  user  specifications  (for  example  on  the  speeds  at  which  the  loads 
should  move  and  the  forces  required  to  move  them)  and  a  utility  function  (say  summing  the  cost 
and  weight),  the  system  takes  about  10  minutes^  to  find  an  optimal  solution. 

Testing  continues;  we  defer  a  detailed  discussion  of  the  capabilities  and  limitations  of  the  inference 
system  and  the  search  procedure  to  [2].  We  present  here  conclusions  based  on  example  problems 
solved  to  date. 

•  Our  language  is  powerful  enough  to  capture  most  of  the  information  provided  in  catalogs  for 
a  wide  range  of  components. 

•  Our  inference  operations  appear  to  result  in  only  correct  eliminations  when  components  are 
appropriately  modelled. 

'  On  a  Symbolics  3640  Lisp  machine,  running  our  unoptimised  research  code. 


cylinders  (12) 

N 

load 

cyiinders(12) 

M 

load 

supply  (6) 

— 

motor8(36) 

— 

pumps(13) 

Figure  7:  A  hydraulic  example 


•  The  idea  that  design  descriptions  represent  sets  of  cirtifacts  and  operating  conditions  is  pow¬ 
erful.  We  could  not  have  worked  through  the  complexities  of  the  theory  without  it. 

•  Our  work  is  incomplete.  For  example,  the  adjustable  position  of  the  seat  back  in  a  automobile 
is  neither  a  parameter  nor  a  state  variable.  We  are  now  exploring  relationships  between 

variables  and  intervals  additional  to  Limits  ([  ]  )  and  Operating- Regions  ).  We  are  at 

present  restricted  to  invertible  algebraic  equations  and  to  positive  values  for  variables.  We 
have  explored  geometric  issues  only  very  lightly.  Our  abstraction  procedures  can  be  made 
stronger.  More  subtly,  “hard-edged”  interval  representations  such  as  ours  distort  the  real 
significance  of  some  specifications[32]. 
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